Systems and methods for operating transaction terminals

ABSTRACT

Methods and apparatus for operating a transaction terminal. In an embodiment, a method includes receiving, by a proximity reader processor via a first channel, an activation signal from a payment terminal processor indicating initiation of a payment transaction with a proximity payment device. The proximity processor then executes a first process having a first queue that causes transmission of first instructions to a second process comprising a second queue, and then the second process is executed to run concurrently with the first process, wherein the second process causes the proximity processor to transmit application activation instructions via a reader interface and a second channel to the proximity payment device. The proximity processor terminates the second process when the application activation is completed without error.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. patentapplication Ser. No. 13/077,626 filed on Mar. 31, 2011, and U.S.Provisional Patent Application No. 61/319,451, filed Mar. 31, 2010,which h patent applications are incorporated herein by reference intheir entirety for all purposes.

BACKGROUND

Payment cards, such as credit cards, debit cards, stored value cards, orthe like are a part of everyday life. For quite some time, most cardshad a magnetic stripe to store payment account information which wasread by a magnetic stripe reader at a point of sale (“POS”) terminal.The magnetic stripe reader would read information including a paymentaccount number from magnetic stripe, and then communicate theinformation to a payment network for processing. The reading of amagnetic stripe is typically an “all or nothing” type of read. Eitherthe reader successfully reads the information or it doesn't. As aresult, POS terminals with magnetic stripe readers are relatively simpledevices.

More recently, payment devices that incorporate an integrated circuit(“IC”) have been utilized as payment cards. Some of these paymentdevices are “contactless” payment devices which communicate with a cardreader via wireless radio frequency (“RF”) communication. One example ofa contactless payment device are the so-called “PayPass” payment deviceswhich operate pursuant to standards developed MasterCard InternationalIncorporated, the assignee hereof Other contactless payment devices andsystems are also in use or in development.

It has been proposed that the capabilities of a contactless paymentdevice be incorporated into a mobile telephone, thereby turning themobile telephone into a contactless payment device. Typically a mobiletelephone/contactless payment device includes integrated circuitry withthe same functionality as the RFID (radio frequency identification) ICof a contactless payment card. In addition, the mobiletelephone/contactless payment device includes a loop antenna similar tothat of a contactless payment device that is coupled to thepayment-related IC for use in sending and/or receiving messages, viashort-distance wireless communications, in connection with a transactionthat involves contactless payment.

Contactless payment devices in other form factors, such as key fobs,wristwatches, wristbands and stickers, have also been proposed. It hasalso been proposed that mobile devices other than mobile telephones—suchas PDAs with mobile communication capabilities—may also incorporatecontactless payment functionality.

In a typical transaction involving a contactless payment device, thecontactless payment device is presented to a contactless readerassociated with a terminal (such as a POS terminal). An interrogationprocess ensues in which the payment device exchanges data with thereader. Device holders who are in a hurry in certain environments (suchas where the contactless payment device is used in a transitenvironment, for example) tend to remove the contactless payment devicefrom communication with the reader quickly. This can result in failedtransactions. It would be desirable to provide systems and methods toallow such failed transactions to be recovered or at least identified.

Further, it would be desirable to provide a reader architecture andmethods which allow the reader and terminal to act in a synchronizedmanner, allowing the logic data associated with (or available to) theterminal to be provided to the terminal in a synchronized or steppedprocess. Still further, it would be desirable to provide a reader whichis capable of communication with a variety of different payment deviceconfigurations.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present invention,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the invention taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates a system provided inaccordance with some embodiments of the present invention.

FIG. 2 is a block diagram that illustrates portions of a system forconducting a transaction involving a wireless device.

FIG. 3 is a block diagram that illustrates portions of a system forconducting a transaction involving a mobile device.

FIG. 4 is a block diagram representation of a terminal and readerpursuant to some embodiments of the present invention.

FIG. 5 is a block diagram representation of a logical architecture of areader pursuant to some embodiments.

FIGS. 6-9 are flow charts that illustrate transaction processesaccording to some embodiments of the present invention.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present invention, a payment reader and terminal are providedwhich allow processing of payment card transactions, includingtransactions involving contactless and other payment devices. Pursuantto some embodiments, the reader and terminal are adapted to processtransactions in a synchronized manner such that the reader requests datafrom the terminal and the terminal can allow for piecemeal or steppedreading of information from the reader and the payment device. In thismanner, embodiments ensure that the reader does not move to the nextphase of a transaction until the terminal has confirmed that the readingphase has been completed. Such a stepped reading of information allowsacollaboration between terminal and reader where the terminal mayrequest data from the payment device during the transaction, may thencondition the transaction on the data provided and may provide data forstorage on the payment device, all during the payment transactionwithout compromising the correctness of the payment transaction flow,and therefore allows the terminal to control the reading process withcertainty. The architecture also facilitates other features to beefficiently and reliably implemented such as recovery from torntransactions and payment device balance reading. As a result,embodiments are particularly suited for use with contactless paymentdevices, including mobile phones and contactless payment cards, even inenvironments where short transaction times are required (such as intransit applications or the like).

A number of transactions involving contactless payment devices aredescribed herein. Those skilled in the art, upon reading thisdisclosure, will appreciate that different payment schemes and protocolsmay utilize features of the present invention with desirable results.For illustration of some features of the present invention, a specificimplementation involving PayPass or EMV compliant payment devices willbe described. Further details of certain transactions involving suchdevices are described in our co-pending and commonly assigned U.S.patent application Ser. No. 12/915,550, filed on Oct. 29, 2010 andentitled “METHODS FOR RISK MANAGEMENT IN PAYMENT-ENABLED MOBILE DEVICE”,the contents of which are hereby incorporated by reference in theirentirety for all purposes.

FIG. 1 is a block diagram that illustrates a payment system 100 providedin accordance with some embodiments of the present invention.

The system 100 includes a contactless payment device 102 which, asdepicted, is embodied in a mobile telephone (e.g., the mobile telephoneis payment-enabled). The payment-enabled mobile telephone 102 may beoperable as a mobile telephone, while also being able to performfunctions of a contactless payment device and to interact with a paymentterminal 106 via a proximity reader 104 configured pursuant toembodiments of the present invention. While the contactless paymentdevice 102 is illustrated in FIG. 1 as being configured as apayment-enabled mobile telephone, embodiments of the present inventionare operable with more traditional form factor payment devices, as wellas payment devices configured as fobs or the like.

The system 100 further includes a proximity reader 104 associated with atransaction terminal 106. The proximity reader 104 and the transactionterminal 106 may be substantially or entirely conventional in theirhardware aspects and may also incorporate conventional softwarecapabilities as well as additional software capabilities provided inaccordance with the present invention and described below. Further, thereader 104 and the terminal 106, although shown as being separate, maybe configured as a unitary component. As such, the terms “terminal” and“reader” as used herein are used to refer to a logical separation ofsoftware or other components, and not necessarily physical separation.The proximity reader 104 is configured to interact with contactlesspayment devices such as device 102 via a contactless interface. In someembodiments, the reader 104 may also be configured with a contactinterface and/or a magnetic stripe reader, allowing the reader 104 tointeract with a variety of different types of payment devices.

As will be recognized by those who are skilled in the art, the proximityreader 104 and the transaction terminal 106 may be, for example, locatedat the premises of a retail store and operated by a sales associate ofthe retailer for the purpose of processing retail transactions. Theproximity payment device 102 is shown in FIG. 1 to be interacting withthe proximity reader 104 and the transaction terminal 106 for thepurpose of executing such a purchase transaction. Some details of thetransaction terminal 106 are presented below in conjunction with FIG. 4.

An acquirer system 108 operated by an acquiring financial institution isalso shown as part of the system 100 in FIG. 1. The acquirer system 108may operate in a conventional manner to receive an authorization requestfor the transaction from the transaction terminal 106. The acquirersystem 108 may route the authorization request via a payment system 110to an issuer system 112 operated by the issuer of a payment account thatis available for access by the proximity payment device 102. Theauthorization response generated by the issuer system 112 may be routedback to the transaction terminal 106 via the payment system 110 and theacquirer system 108.

The payment system 110 may be entirely or substantially conventional;one example of a suitable payment system is the well-known BankNetsystem operated by MasterCard International Incorporated which is theassignee hereof.

In general, the issuer system 112 may be operated by or on behalf of afinancial institution that issues payment card accounts to individualusers. The issuer system 112 may perform functions, such as (a)receiving and responding to requests for authorization of paymentaccount transactions to be charged to payment card accounts issued bythe issuer; and (b) tracking and storing transactions and maintainingaccount records.

The components of the system 100 as depicted in FIG. 1 are only thosethat are needed for processing a single transaction. Those skilled inthe art will recognize that a practical embodiment of the system 100 mayprocess many purchase transactions (including simultaneous transactions)and may include a considerable number of payment card issuers and theirsystems, a considerable number of acquirers and their systems, andnumerous merchants and their transaction terminals and associatedreaders. The system may also include a very large number of payment cardaccount holders, who carry payment devices.

Pursuant to some embodiments, the terminal 106 is configured, pursuantto the present invention, to delegate payment processing to the reader104. In this manner, the terminal 106 may focus its processing on itsown business logic, which may include storage of data on the proximitypayment device 102. The terminal 106 may include business logic andsoftware which allows the terminal 106 to perform processing to supporttransactions, such as, for example, determining the transaction amount(although in some cases, the transaction amount may be determined basedon information retrieved from the proximity payment device 102 or usingother techniques), as well as performing transaction logging to storetransaction clearing records and to prepare batch files or real-timemessages for submission to the acquirer systems 108. In someembodiments, the terminal 106 may also include data storage logic toanalyze (and possibly update) data received from the proximity paymentdevice 102 via the reader 104. For some transactions or environments,the terminal 106 may also include security logic to check and protectthe integrity of data received from the proximity payment device 102 viathe reader 104.

Pursuant to some embodiments, the reader 104 is configured to interactwith the proximity payment device 102 during the course of atransaction. Where needed, the reader 104 is operable to pass data fromthe proximity payment device 102 to the terminal 106 and from theterminal 106 to the payment device 102 during the payment transaction.The reader 104 may include processing logic and memory allowing thereader to collect necessary data from the payment device and to obtain atransaction authorization as well as to populate a clearing record fortransmission from the terminal 106 to the payment system 110. Insituations where the payment device holder needs to be verified thereader 104 is configured to perform such an verification process.Further, the reader 104 is configured with storage logic to read datafrom the payment device 102, track torn transactions (as describedfurther below) and write data back to the payment device 102.

Pursuant to some embodiments, communication between the reader 104 andthe terminal 106 is via signals which are asynchronous events that areplaced in a process queue and that are handled in a first-in, first-outbasis. Pursuant to some embodiments, the terminal 106 and the reader 104may be viewed as each having one queue, even if internally the terminal106 and the reader 104 have multiple queues. Further details ofcommunication between the terminal 106 and reader 104 will be describedfurther below. However, in general, the terminal 106 is in control ofactivating and deactivating the reader 104 and is in control of thereader as needed to update the database of the reader 104, update thecurrent transaction dataset of the reader 104, and request data from thereader 104. The reader 104 is provided with software (including “kernel”software as described herein) which is in overall control of thetransaction flow involving the payment device 102. It is also possibleto implement the same functionality with a model that manages signals inmultiple queues per process or uses other forms of inter processcommunications other than signals. The term signal is used genericallyhere as a standard way to describe various inter-process communicationmechanisms.

Pursuant to the present invention, the terminal 106 and the reader 104are synchronized such that if the reader requires information during atransaction with a payment device 102 it will request the informationfrom the terminal 106 and wait until it receives the information.Further, the terminal 106 may provide information earlier than needed bythe reader in order to allow the reader and any active processes toproceed efficiently without any unnecessary time delays. The terminal106 may also withhold data in order to cause the active process in thereader 104 to request the data so that the terminal may make adetermination about subsequent actions. In general, the reader 104 mayrequest data from the terminal using a request message. The use of sucha request message allows the terminal 106 to stay in synch with thereader 104. Such a synchronized process provides a number of advantagesduring the processing of transactions as will be hereinafter describedand which will become apparent to those skilled in the art.

FIG. 2 schematically illustrates some communication aspects of a typicaltransaction in which a proximity payment device 102 is used. Theterminal is represented by item 106, and the reader is represented byitem 104. Wireless communication between the proximity payment device102 and the reader 104 is indicated at 202. The wireless communication202 may be conducted in accordance with one or more standard protocols,such as “EMV Contactless” and/or NFC all of which are well known tothose who are skilled in the art. The device 102 may be apayment-enabled mobile telephone or other form factor proximity paymentdevice.

FIG. 3 schematically illustrates some physical aspects of a purchasetransaction. As in FIG. 2, the terminal 106 and its associated reader104 are shown. The proximity payment device 102 (depicted as apayment-enabled mobile telephone) is also shown in proximity to thereader 104. In a common manner of initiating the wireless communicationdepicted in FIG. 2, the user of the proximity payment device 102 brieflytaps the proximity payment device 102 at a particular location on thereader 104. The location on the reader 104 at which the proximitypayment device 102 is to be tapped may be indicated to the user by astandard logo affixed to the reader 104, such as the “PayPass” logo oranother industry specific contactless identifier.

FIG. 4 is a block diagram of a typical embodiment of the terminal 106depicted in FIG. 1. As shown, a reader 104 is in communication with theterminal 106. In some embodiments, the terminal 106 and the reader 104may be largely or entirely conventional in their hardware aspects.Nevertheless, the terminal 106 and reader 104 may be programmed inaccordance with features of the present invention to providefunctionality as described herein.

The terminal 106 may include a processing element (or elements) such asthe processor 402 shown in FIG. 4. The processor 402 may for example bea conventional microprocessor, and may operate to control the overallfunctioning of the terminal 106. It may also be implemented as multiplemicroprocessors for speed. The terminal 106 may also includeconventional peripheral components, in communication with and/orcontrolled by the processor 402, such as one or more of: (a) a keypad404 for receiving input from a human operator of the terminal; (b) abarcode reader 406 for reading product barcodes from products brought tothe terminal for purchase; (c) a cash drawer 408 for storing cashreceived from customers in certain transactions; (d) one or moredisplays 412 for providing output (e.g., identifying products presentedfor purchase and their prices, indicating sales tax due, indicatingtransaction subtotals and totals, etc.); (e) a printer 414 for printingout sales receipts; (f) the above-mentioned reader 104, for exchangingwireless short range communications/near field communications (NFC) withproximity payment devices (as well as, in some embodiments, magneticstripe devices and contact payment devices); and (g) a communicationcontroller 418 for allowing the processor 402, and hence the terminal106 to engage in communication over data networks with other devicessuch as a merchant processing system (not shown), and an acquirer(FIG. 1) or its transaction processor (not shown). In some embodiments,at least one of the displays 412 may be a touch screen, so as to providean input function as well as an output function. In some embodiments,the terminal 106 may also include a magnetic stripe reader for readingpayment card account numbers and related information from magneticstripe payment cards. In some embodiments, the magnetic stripe readermay be embodied in or associated with the reader 104.

In addition, the terminal 106 may include one or more memory and/or datastorage devices (indicated collectively at 420), which may comprise anycombination of one or more of a hard disk drive, RAM (random accessmemory), ROM (read only memory), flash memory, etc. The memory/datastorage device(s) 420 may store software and/or firmware that programsthe processor 402 and the terminal 106 to perform functionality asdescribed herein. Further, the terminal 106 may include one or morehousings (not shown) which contain and/or support one or more of theother components shown in FIG. 4.

As shown, the reader 104 also includes a reader datastore for use instoring data such as kernel data as well as a torn transaction log aswill be described further below. In some embodiments, the reader 104also includes a processor, communications controller and storage devicesto store software and/or firmware that programs the reader 104 toperform functions as described herein.

Reference is now made to FIG. 5, where a block diagram is shown whichdepicts a logical model 500 of the reader 104 and communication betweenthe reader 104, the terminal 106, and the payment device 102. Each ofthe processes depicted in the logical model refer to logical processesthat may be deployed using a software kernel executed by a processor ofthe reader 104. As depicted, three processes are shown. However, thoseskilled in the art upon reading this disclosure will realize thatfurther processes may be employed based on the complexity orrequirements of different transaction processes or implementations. Asan example, a 4th process may be implemented to manage the routing ofcommunications to the payment device 102. Signals may also be routeddifferently, for example the CON signal conveying transaction specificdata to the kernel may be sent directly and not via Process 1. As shown,the reader 104 has several communications channels—a first channelbetween the reader 104 and the terminal 106, and a second channelbetween the reader 104 and the payment device 102. Each of the processes(which are labeled as “Process 1”, “Process 2” and “Process 3”)communicates with other processes by sending signals over thesechannels. The signals get queued, and are handled as events. At the sametime that these processes and signals are managed, the reader 104 alsomaintains a reader data store (shown in FIG. 4) which maintains a numberof separate datasets. The datasets may include static as well astransient datasets.

Pursuant to some embodiments, each of the processes in the reader 104run concurrently with the other processes and implement a state machine.Each process has one queue for incoming signals, and all incomingsignals are placed in that queue. As depicted, “Process 1” is a readermanagement process which is the initial state of the reader 104. Thisprocess controls the overall functions of the reader 104 and managessignals received from the payment device 102 and the terminal 106. Forexample, the terminal 106 may request that the reader 104 update itsdatabase (e.g., for use in processing a transaction) or request that thereader 104 begin processing a transaction. As shown, the terminal 106may issue a signal such as “ACT” to activate the reader in order toperform a transaction (which command may be provided with transactionspecific data such as a transaction amount). The terminal may also issuea “CON” signal to instruct the reader to continue. The CON signal may beprovided with data needed for the specific transaction in progress andindicates to the reader 104 that the reader should proceed with thetransaction. The CON signal may be sent in reply to a REQ (or request)signal sent from the reader to the terminal, or it may be sentspontaneously by the terminal 106. An “UPD” signal sent by the terminalmay include data to manage the reader's datastore, and may include alist of data items to be added to the datastore and/or a list of itemsto be deleted. A “STOP” signal may be transmitted to indicate that thereader should stop or abort a transaction (e.g., where the terminal hasdetected an error or anomaly in the transaction).

The reader 104 may similarly send signals to the terminal 106 overchannel 1. For example, the reader 104 may transmit a “REQ” signal tothe terminal indicating a request for extra data that may be required tocomplete a current transaction. The REQ signal may also be used toprovide information to the terminal 106, either because the reader 104knows it is needed for further processing or because the terminal 106specifically requested the data. The reader 104 may also transmit asignal indicating that a transaction is “DONE” or “NOTDONE” (for successor failure of a transaction). Such signals may further include dataspecifying the results of the transaction. For example, in the event ofa successful completion of a transaction, the reader may transmit a“DONE” signal along with transaction clearing information and other dataneeded by the terminal 106 to initiate clearing and settlement of thepayment transaction. The issuance of a “DONE” signal does notnecessarily mean that a transaction has been approved, it merely signalsthe completion of the transaction.

The reader 104 is also shown as having two other processes. “Process 2”is a process that is started by Process 1 (e.g., after Process 1receives an ACT signal from the terminal 106), and is used to performapplication activation on the payment device 102 (e.g., operation ofProcess 2 causes an card activation message (“CA”) to be transmitted tothe payment device 102 over channel 2. If the activation is completedwithout error, Process 2 is terminated (with a “DONE” or “NOTDONE”signal passed back to Process 1) and a kernel will be executed bystarting Process 3.

Process 3 is executed based on the outcome of Process 2, and may furtherdepend on data retrieved from the card (via R2). In a plain or standardpayment transaction, the kernel of Process 3 will execute, complete andinform Process 1 of the results (e.g., “DONE”, “NOTDONE”) and then exit.For transactions involving data storage, however, some interaction withthe terminal may be required. For example, the kernel of Process 3 mayrequest data (“REQ”) from the terminal 104 and/or pass data to theterminal. The terminal may respond accordingly with a signal which mayinclude data. Different payment applications may involve the use ofdifferent kernels. However, in some embodiments, even where additionalkernels are provided, only one process 3 will execute at a time, and theadditional kernels will execute as Process 3 (i.e., the overall readerprocess and the activation process will still likely exist, however theadditional kernels will each execute as Process 3).

The reader 104 exchanges signals with the payment device 102 via channel2. In general, pursuant to some embodiments, communications with thepayment device 102 are in command/response pairs (e.g., pursuant to theEMV specification or the like). The data and signals passed back andforth between the reader 104 and the payment device 102 may depend onthe specific payment scheme (e.g., EMV or the like), as well as thespecific payment application involved in the transaction.

In some situations, the reader 104 may receive data (either from theterminal or the payment device) which is to be stored in a readerdatabase. Both static and transient datasets may be stored. A genericdataset may be stored which is a set of Tag-Length-Value (TLV) dataobjects that includes persistent data not specific to a particulartransaction or to a specific kernel (e.g., such as a terminal countrycode). TLV coding is commonly used in smart card and payment systemssuch as EMV but other representations are equally valid. Kernel specificdata may also be stored, which includes TLV data objects and persistentdata that may differ from kernel to kernel and that are not transactionspecific (such as tag and data items that are payment system specific,such as a terminal's cardholder verification method (“CVM”) limit, orthe like). In some embodiments, datasets stored in the reader databasemay be populated during the course of a transaction (triggered byreceipt of the “ACT” or activate signal from the terminal 106). Thistransaction data may be updated during kernel processing and may includeTLV data associated with the transaction (such as amount and authorizeddata). Further, the reader database may include data resulting fromProcess 2 processing (e.g., such as FCI data returned from paymentapplication selection on the payment device 102). When the kernelprocess associated with Process 3 is started, the reader managementprocess (Process 1) provides a copy of the complete reader database tothe kernel, providing the kernel with all the context and informationneeded to process the transaction.

The concept of this structured, synchronized architecture and the dataexchange mechanisms described above may be extended to provide furtherprocesses and functionality at the reader 104. For example, a readerlogical architecture may be provided which includes a number of definedprocesses in addition to those described above in conjunction with FIG.4. For example, in one embodiment, the reader 104 is provided with amain process (similar to “Process 1” described above) which performsreader management functions including overall control and sequencing ofthe different reader processes. In some embodiments, this main processis responsible for coordinating the other processes, configuring andactivating any kernel processes and for the processing of any outcomes.Additional processes may be provided to provide certain services, suchas a process for managing the contactless interface, a process formanaging the user interface, a process for selecting the relevantpayment device application and kernel, and a kernel process forinteracting with the payment device once the application has beenselected. Other processes may also be provided. Pursuant to the presentinvention, each of the processes runs independently of the otherprocesses and implement a state machine. Each process has a single queuefor incoming signals and all signals are placed in that queue. Byproviding such a configuration, the reader and terminal are able tointeract in a controlled and synchronized fashion.

By using such a structured, synchronized architecture for readerprocessing, embodiments allow the terminal 106 and the reader 104 toremain in step during the course of a transaction. This has a number ofbenefits, one of which will now be illustrated by describing a processwhere the terminal business logic may wish to condition the amount ofthe transaction dependent on specific non payment data stored on thepayment device such as a club, entitlement or loyalty identifier. Thissimple example is designed to illustrate the process architecture,separating payment transaction flow from business logic in the readerand terminal respectively. A more complex example will be presentedlater after the processing of torn transactions has been described.

With reference to FIG. 5, the terminal commences the transaction bysending an ACT signal to the Reader 104 with an Amount for thetransaction. It also, either in the ACT signal or pre-configured in thedatabase with an UPD signal, indicates that it wishes a specific TLVdata item to be read from the payment device, if it exists, and sent tothe terminal. The reader 104 activates the payment device 102 and,following the decision of Process 2 on the type of payment devicepresented, initiates the appropriate kernel as Process 3. Process 3 willbe given the request from the terminal 106 and will commence thetransaction flow as defined, for example, in EMV. When it encounters thespecific TLV data item requested by the terminal 106 it will immediatelysend a signal to the terminal 106 with the referenced data. It will thencontinue the processing of the transaction as far as it can without aresponse from the terminal 106. Typically, this means that it willcontinue to process EMV “Read Record” commands as defined by the EMV“Application File Locator” until it has read all data. It may also thenperform internal risk management of offline data authentication butcannot proceed to complete the transaction without information from theterminal 106. This information, provided by the terminal 106 in a CONsignal may contain, for example, an updated transaction amount. Theterminal 106 may have been computing this in parallel with the reader104 processing of the transaction therefore significantly improvingperformance over commonly found terminal/reader implementations whicheither cannot perform this type of logic or would incur a time penaltyin the middle of the transaction.

Many other variations on the business logic are possible, for example asdescribed later the terminal may wish to store data back to the paymentdevice during the transaction, it may wish to ask for additional datadepending on the first data received, it may wish not to proceed at all(and STOP the transaction) or it may wish to know the offline balance ofthe payment device 104 beither before or after the transaction iscompleted. The architecture of FIG. 5 is an efficient way to supportthese future business requirements without requiring the terminal 106 tounderstand the payment logic or the reader 104 to change every timebusiness requirements of the terminal change.

The reader architecture also efficiently permits for recovering from“torn” transactions (where a payment device is removed prematurely froma reader 104, thereby interrupting the normal completion of thetransaction). Such “torn” transactions may be particularly common inenvironments such as transit or quick serve restaurants where consumersare in a hurry. If a payment device 102 is removed from a reader 104before the transaction has completed, the natural behavior of theconsumer may be to try again. If the payment device 102 maintains anoffline balance (e.g., the payment device is a prepaid or preauthorizedproduct, which is common in transit and quick serve restaurantenvironments), then the counters in the payment device 102 applicationmay have been decremented. Repeating the transaction would mean that theconsumer will effectively pay twice or may believe that they have paidtwice, until clearing resolves the issue. In some situations, denial offurther use of the payment device may occur if the balance hasdecremented and the merchant has not been paid. While other mechanismsare typically implemented to avoid or reduce the likelihood of a torntransaction occurring, there is still often a window of time in which atorn transaction can result. Embodiments provide mechanisms that allow areader 104 to recover from a torn transaction. Again, the reader 104effectively hides the transaction logic from the terminal 106 and theterminal, whilst informed of the fact that the transaction has (or hasnot) been recovered need not concern itself with the mechanisms.

Pursuant to some embodiments, a signal referred to as the “Recover AC”command is provided to enable recovery of a torn transaction (where theterm “AC” refers to an “Application Cryptogram” as the term is used inthe EMV specifications available at www.emvco.com). In generalembodiments operate as follows. First, if the reader 104 failed toreceive a response to a command from the payment device it may ask forit again on the next transaction by issuing a “Recover AC” command. Forexample, the reader may be expecting a response to the EMV “Generate AC”command which sends transaction-related data to the payment device,which then computes and returns an Application Cryptogram). Pursuant toEMV standards and depending on the risk management in the paymentdevice, the cryptogram returned by the payment device may differ fromthat requested in the command message from the reader. The paymentdevice may return an “AAC” (transaction declined), an “ARQC” (onlineauthorization request), or a “TC” (transaction approved). Furtherdetails of the AC and interactions between the reader and the cardduring EMV-compliant payment transactions are available atwww.emvco.com. If the customer had removed the payment device 102 fromthe reader 104 too soon, the reader will never receive the AC and itwill “time-out” the transaction. The merchant will typically ask for thepayment device 102 to be presented again. The terminal 106 does not needto know about transaction recovery, it merely wishes to transact andinstructs the reader accordingly. The reader needs to handle therecovery whilst honoring the request of the terminal 106.

If the reader 104 does not receive a response to the Generate AC commandand timed out the first attempted transaction, it will log this fact andthe corresponding transaction data in its database. When the samepayment device 102 is presented a second time it may ask for theoriginal result again by issuing a “Recover AC” command. If the paymentdevice 102 had not advanced so far in its transaction as to update itscounters and create the response to the Generate AC command and createthe response, then the payment device 102 will respond to the reader 104by sending a response indicating that it cannot recover (e.g., there isnothing to recover as no AC exists), and the reader 104 will immediatelyask for a new Application Cryptogram as per the request from terminal106. If, however, the payment device 102 had updated its counters andresponded, but for some reason (e.g., a torn transaction) the responsewas not received by the reader 104, then the payment device 102 willprovide the original response again. In some embodiments, where thepayment device 102 does not support transaction recovery, then thereader 104 will continue with a new transaction. In order to providethis processing, the reader 104 stores and maintains a torn transactionlog in the reader data store (as shown in FIG. 4). The reader 104 maypurge the torn transaction log after each transaction is successfullycompleted.

Reference is now made to FIG. 6 where a process 600 for identifying atorn transaction is shown. Process 600 may be performed by the reader104 under control of software and code to provide an executable processfor identifying a torn transaction. The process 600 begins at 602 wherethe reader 104 reads application data from the payment device 102 (e.g.,during a contactless interaction between a payment device and thereader, such as in a payment transaction). The application data mayinclude reading the primary account number (“PAN”) and PAN sequencenumber (“PSN”) from the payment device. Processing continues at 604where the reader 104 checks for a matching entry in the torn transactionlog (e.g., an entry with the same PAN and PSN). If the reader determinesthat there is a log entry at 606, processing continues at 608 where thereader 104 attempts recovery of the previous transaction. For example,the reader 104 may transmit a signal to the payment device 102 such as a“Recover AC” command s described in conjunction with FIG. 8.

If processing at 606 reveals no matching log entry, processing willcontinue at 610 with normal transaction processing. If there was aprevious torn transaction, but there was no matching transaction recordin the torn transaction log, then it is likely that a previous attemptat recovering the torn transaction failed and the entry in the torntransaction log was erased (e.g., such as at step 804 of FIG. 8).

Reference is now made to FIG. 7, where a process 700 is shown forlogging a torn transaction. The process 700 is invoked when a timeoutoccurs during a transaction involving a reader 104 and payment device102 (e.g., such as when a timeout occurs during processing of a“Generate AC” command in the case of EMV payment transactions). As shownin FIG. 7, at 702 during a transaction, the reader 104 issues a“Generate AC” command to the payment device 102. In the case of a normal(non-torn) transaction, the reader 104 will receive a response to thecommand, and processing will continue as normal at 706. However, if thereader 104 does not receive a response within an expected time period, atimeout is identified at 704 and processing continues at 708 where thereader 104 determines whether the payment device 102 involved in thetorn transaction supports recovery pursuant to the present invention(e.g., whether the payment device is capable of processing a “RecoverAC” command). In some embodiments, the reader may determine whether thepayment device 102 supports transaction recovery by reading a dataelement previously provided by the payment device. For example, the dataelement may be referred to as a “Data Recovery DOL” (DRDOL) dataelement. If the reader 104 did not read a DRDOL element from the paymentdevice 102, then torn transaction recovery cannot be performed andprocessing continues at 716 where the transaction is completed and thetransaction is declined.

If, however, the reader 104 did read a DRDOL element from the paymentdevice 102, then processing continues at 710 where the reader 104determines whether a free entry in the torn transaction log isavailable. In general, in some embodiments, if an entry already existsin the torn transaction log then a new entry will be added for thepresent transaction, however, in some embodiments, only a single entryin the log may be permitted. If adding a new entry to the log means thatan old record will be displaced, then the old record may be transmittedto the terminal 106. Processing continues at 714 where the transactiondetails associated with the present torn transaction are inserted intothe torn transaction log. In some embodiments, the log is updated withthe data associated with the DRDOL as well as information identifyingthe PAN and PSN of the payment device associated with the torntransaction. Processing continues at 716 where the transaction iscompleted (as declined).

Reference is now made to FIG. 8 where a process 800 for recovering atorn transaction is shown. Process 800 may be performed by the reader104 after processing of FIG. 6 (e.g., after processing at step 608 andafter the reader has determined that a torn transaction entry is in thetorn transaction log associated with the payment device 102 involved inthe instant transaction). Recovery processing begins at 802 where thereader 104 issues a “Recover AC” command or similar signal to thepayment device 102. Upon issuing the Recover AC command, in someembodiments, the reader 104 erases the entry from the torn transactionlog (to ensure that recovery is not attempted more than once) but it isequally possible to perform step 804 after step 806 if multiple attemptsat recovery are desirable. Processing continues at 806 where the reader104 determines whether a response to the Recover AC command has beenreceived or if a timeout has occurred. If a timeout has occurred,processing continues at 808 and the transaction is terminated. In someembodiments, the reader may transmit a status of the recovery to theterminal 106 (e.g., such as a status of ‘undetermined card update’) aswell as transaction log details. Otherwise, processing continues at 810where a determination is made whether an AC has been returned from thepayment device 102. If not, processing continues at 812 where the reader104 includes a status of the recovery attempt (e.g., ‘no card update’)in the transaction outcome details and transmits them to the terminal106. The reader 104 may then continue normal transaction processing(e.g. by issuing a “Generate AC” command) to complete the transaction asa new transaction with the payment device 102.

If processing at 810 indicates that no AC was received from the paymentdevice 102, processing continues at 814 where the reader 104 attempts tovalidate the AC received from the payment device 102. For example, thereader 104 may use standard EMV processing techniques to validate theAC. If the AC is valid, processing continues at 820 where thetransaction is terminated and a status is set (e.g., ‘confirmed cardupdate’) and the torn transaction has been successfully recovered.Transaction details are transmitted to the terminal for clearingprocessing. If processing at 816 results in no validation of the AC,processing continues at 818 where the transaction is terminated and astatus is set (e.g., ‘undetermined card update’) and transaction logdetails are transmitted to the terminal 106.

In this manner, embodiments allow the recovery of torn or interruptedtransactions. The data stored in the reader's torn transaction log maybe erased after a few moments to minimize storage requirements or fordata security compliance reasons. This “housekeeping” may be performedautonomously by the reader 104 and any erased entries may be sent assignals to the terminal 106 in case the terminal wishes to performadditional business logic processing on these failed transactions (forexample if data storage had been performed in the transaction andelectronic goods or entitlement supplied). Further, the torn transactionlog may store different types of data for different environments.

The reader 104 may further be operated to determine an appropriatemethod of transaction data storage for each transaction in conjunctionwith terminal 106. In some embodiments, several data storage options maybe provided. Reference is now made to FIG. 9 where a process 900 foroperating a reader 104 to determine an appropriate storage approach isshown. Pursuant to some embodiments, the payment device 102 can be usedas a scratch pad or mini data store with simple write and readfunctionality. In some embodiments, several types of data storage arepossible: standalone data storage (“SDS”), integrated data storage(“IDS”), or no data storage. The process 900 may be performed when thereader 104 receives data from a payment device 102 during a transaction.Processing begins at 902 where the reader receives application data fromthe payment device. For example, the application data may be receivedafter a process of the reader issues a signal to the payment device 102selecting an application on the device. The payment device 102 respondswith application data and payment device information. Pursuant to someembodiments, the response data includes an indicator specifying whetherthe payment device supports data storage or not. If the payment devicedoes not support data storage, processing continues at 908 where no datastorage on the device is used, and the transaction processing continuesas normal. If a flag or indicator in the payment device data indicatesthat data storage is supported, processing continues at 910 where adetermination is made whether IDS storage is supported. If so (and ifthe reader supports it), processing continues at 914 and IDS datastorage is utilized for the transaction processing. If not (and if thereader supports SDS), processing continues at 912 and standalone datastorage (SDS) is used.

The terminal 106 would in initiating a transaction with an ACT signal,inform the reader 104 whether it wished to engage in data storage ornot. The reader 104 would, if it also recognized data storageavailability on the payment device 102, recover the data requested bythe terminal 106 and send to the terminal 106 as previously describedusing signals. It would continue in parallel with the processing of thetransaction flow reading other data from the card and would eithercomplete the transaction without updating the data on the card or wouldreceive signals from the terminal 106 with new data to be written whichwould be interleaved with the transaction flow by reader 104.

Pursuant to some embodiments, SDS uses dedicated commands (e.g., such as“GET DATA” and “PUT DATA”) for explicit reading and writing of data. Inthis case the terminal 106 would indicate in an ACT, UPD or CON signalthe specific TLV data that it wished to read or write. In someembodiments, IDS builds the reading and writing functions into existingpayment application processing commands. For example, a secure paymentsolution may be provided without requiring a secret key to be sharedbetween the terminal 106, the reader 104 and the payment device 102.Similarly to the SDS case, the terminal 106 would indicate its desirefor data storage in an ACT or UPD signal, would be provided with thedata in a REQ signal and would provide new data to be written in a CONsignal. Further, because the IDS data storage functionality integratesthe non-payment data into existing payment commands, payment and datastorage may be performed as part of the same transaction. As data iswritten to the payment device, each data object is qualified as eitherpermanent or volatile, where the permanent objects are protected againstunauthorized overwriting. In some embodiments, the volatile objects canbe written freely, but may be discarded later if the payment device runsout of available data slots. In some embodiments, the non-payment datais provided to the payment device in a command such as the “Generate AC”command described above.

By allowing the use of such data storage options, compatibility with awide variety of readers and payment device schemes may be achieved.Further, as payment devices 102 adopt the IDS data storage options,greater security and efficiency may be provided.

As used herein and in the appended claims, the term “acceptance entity”refers to a retailer or other organization that operates a proximityreader to read information from a payment-enabled mobile device.

As used herein and in the appended claims, a “currency indicator” is acode or data element that indicates what currency, if any, the currenttransaction is being conducted in. The currency indicator may be a nullindicator that does not indicate a specific currency.

The nonvolatile memory referred to herein may be composed of one deviceor of two or more devices.

As used herein and in the appended claims, a program or device is“configurable between” two or more distinct configurations if input maybe provided to the program or device to select between or among theconfigurations.

Relative to a proximity payment device and a proximity reader, the term“tap” refers either to brief physical contact, or relative positioningsuch that wireless communication occurs.

As used herein and in the appended claims, the term “computer” should beunderstood to encompass a single computer or two or more computers incommunication with each other.

As used herein and in the appended claims, the term “processor” shouldbe understood to encompass a single processor or two or more processorsin communication with each other.

As used herein and in the appended claims, the term “memory” should beunderstood to encompass a single memory or storage device or two or morememories or storage devices.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable.

As used herein and in the appended claims, the term “payment cardaccount” includes a credit card account, stored value account or adeposit account that the account holder may access using a debit card.The term “payment card account number” includes a number that identifiesa payment card account or a number carried by a payment card, or anumber that is used to route a transaction in a payment system thathandles debit and/or credit transactions. The term “payment card”includes a credit card or a debit card.

As used herein and in the appended claims, the term “payment cardsystem” refers to a system for handling purchase transactions andrelated transactions and operated under the name of MasterCard, Visa,American Express, Diners Club, Discover Card or a similar system. Insome embodiments, the term “payment card system” may be limited tosystems in which member financial institutions issue payment cardaccounts to individuals, businesses and/or other organizations.

Although the present invention has been described in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the invention as set forth in the appended claims.

What is claimed is:
 1. A payment terminal comprising: a payment terminalprocessor; a communications controller operably coupled to the paymentterminal processor; a terminal data storage device operably coupled tothe payment terminal processor; and a proximity reader operably coupledto the payment terminal processor, the proximity reader comprising: aproximity processor; a reader storage device in communication with theproximity processor and storing a reader control program; a readerinterface operably connected to the proximity processor, the readerinterface configured to communicate with a payment device; and whereinthe reader control program comprises instructions configured to causethe proximity processor to: receive an activation signal via a firstchannel from the payment terminal processor, the activation signalindicating initiation of a transaction involving a proximity paymentdevice with the proximity reader; execute a first process causingtransmission of first instructions to a second process, wherein thesecond process causes transmission of second instructions via the readerinterface and a second channel to a proximity payment device; andwherein the first process comprises a first queue and the second processcomprises a second queue in which received instructions are placed andhandled in a first in first out basis allowing each of the first andsecond processes to run concurrently with each other.
 2. The paymentterminal of claim 1, wherein the reader control program comprisesfurther instructions configured to cause the proximity processor totransmit data received from a proximity payment device to the paymentterminal processor via the first channel.
 3. The payment terminal ofclaim 2, wherein, subsequent to receiving the proximity payment devicedata from the proximity processor, the payment terminal processortransmits the proximity device data via the communications controller toat least one of an acquirer computer and a merchant processing system.4. The payment terminal of claim 1, wherein the first process comprisesa reader management process controlling the overall functions of theproximity reader and managing communications between the proximityprocessor and the payment terminal processor.
 5. The payment terminal ofclaim 1, wherein the reader control program comprises furtherinstructions configured to cause the proximity processor to execute athird process upon receipt of instructions from the first process,wherein the third process comprises a third queue in which receivedinstructions are placed and handled in a first in first out basisallowing the third process to run concurrently with the first processand the second process, and wherein the third process causestransmission of third instructions via the reader interface and thesecond channel to a proximity payment device.
 6. A payment terminalprocess, comprising: receiving, by a proximity processor of a proximityreader via a first channel, an activation signal from a payment terminalprocessor indicating initiation of a payment transaction involving aproximity payment device; executing, by the proximity processor, a firstprocess comprising a first queue in which received instructions areplaced and handled in a first in first out basis, the first processcausing the proximity processor to transmit first instructions to asecond process comprising a second queue in which received instructionsare placed and handled in a first in first out basis; executing, by theproximity processor, the second process to run concurrently with thefirst process, the second process causing the proximity processor totransmit application activation instructions via a reader interface anda second channel to the proximity payment device; and terminating, bythe proximity processor, the second process when the applicationactivation is completed without error.
 7. The method of claim 6, furthercomprising transmitting, by the proximity processor to the paymentterminal processor via the first channel, data received from theproximity payment device.
 8. The method of claim 6, further comprisingexecuting, by the proximity processor a third process upon receipt ofinstructions from the first process, wherein the third process comprisesa third queue in which received instructions are placed and handled in afirst in first out basis allowing the third process to run concurrentlywith the first process and the second process.
 9. The method of claim 8,wherein the proximity processor controls the third process to completeprocessing, inform the first process of the results, and exit.
 10. Themethod of claim 8, wherein the proximity processor controls the thirdprocess to request data via the first channel from the payment terminalprocessor, receive a response, inform the first process of the results,and exit.
 11. The method of claim 6, wherein the first process is areader management process controlling overall functions of the proximityreader including overall control and sequencing of reader processes. 12.The method of claim 6, wherein the first process is a reader managementprocess coordinating other processes, configuring and activating kernelprocesses, and processing outcomes.